About ABAP Data Clusters
Unlike most of the rest of the SAP R/3 system, the HR module stores much of its data in ABAP data clusters rather than in data dictionary tables such as Transparent, Pool, or Cluster Tables.
Data “clusters” are actually stored in some transparent tables.  Any such transparent table can contain many different types of “clusters”.  Each “cluster” of data is stored in one or more rows in the Transparent Table.  A cluster can contain any number of individual components or “pieces” of data, which may range from single values to structures to tables.  A data cluster is accessed by running the ABAP command IMPORT which takes parameters such as cluster database name, cluster ID, etc, as well as a list of pieces of data to “IMPORT”.  The IMPORT command copies the contents of the data cluster into local variables within the calling code.  A typical Transparent Table that contains cluster data has a structure similar to:
<client>:<area>:<key>:<line counter>:<user data>:<data length>:<data cluster>
The combination of Transparent Table name and area identify which type of cluster to import, while the key identifies the specific cluster.  For HR, the cluster key is typically some combination of personnel # and something else.  The key is stored in a single text field, but actually may represent more than one logical key field (e.g. personnel number + a sequence number for HR Payroll data).
Cluster Data Access Overview
The difficulty in working with clusters from a generic, relational data access point of view is that the structure of clusters is not stored in any repository such as the data dictionary.  Furthermore, the format of these clusters may change from site to site due to customizations.  Also, it is fundamentally difficult to map these as tables in the relational sense because, although the data represented is relational, it is stored in independent clusters in an almost hierarchical form. 
In order to access clusters from Seagate products, the individual components of data clusters are mapped as tables within Seagate’s framework.  This is done by creating a “Dictionary” of the clusters on a particular R/3 system, and having a driver which is aware of this dictionary and uses it to provide access clusters within Seagate’s database manager. 
The Cluster Dictionary
The cluster “dictionary” consists of 3 transparent tables, which are part of the server-side transport done for the driver.  Following is a description of the 3 tables and a diagram showing their relationship to each other.

ZCLUSTID (Table that holds list of all clusters)
Fieldname	Description	
DBNAME	Name of cluster database (e.g. PCL2)	
RELID	Cluster area (e.g. RU)	

ZCLUSTKEY (Table that holds definition of the fields that make up the key for a cluster)
Fieldname	Description	
DBNAME	Name of cluster database (e.g. PCL2)	
RELID	Cluster area (e.g. RU)	
KEYNUM	Sequence # for the key field being specified (e.g. 001, 002, …)	
KEYNAME	Name to use for this key field inside Seagate Software (e.g. PERNR)	
REFTABNAME	Name of table to refer to for type of this key field, if any (e.g. PC200)	
FIELDNAME	Name of field within table to refer to for type of this key field, if any (e.g. PERNR)	
INTTYPE	ABAP type of this key field, if not referring to a DDIC field (e.g. N)	
INTLEN	Internal length of this key field, if not referring to a DDIC field (e.g. 8)	

ZCLUSTDATA (Table that holds definition of the fields that make up a piece of data within a cluster)
Fieldname	Description	
DISPNAME	Name to display for this data piece, in Crystal Reports/Info (e.g. RURT)	
DBNAME	Name of cluster database (e.g. PCL2)	
RELID	Cluster area (e.g. RU)	
PIECENAME	Name this data piece was exported to (e.g. RU)	
PIECECLASS	“Class” of this data piece ((T)able, (S)tructure, (B)asic Type)	
REFTABNAME	Name of table to refer to for structure of this data piece, if any (e.g. PC207)	
FIELDNAME	Name of field within table to refer to for type of this data piece, if it’s a (B)asic type 	
INTTYPE	ABAP type of this data piece, if it’s a (B)asic type and not referring to a DDIC field (e.g. N)	
INTLEN	Internal length of this data piece, if it’s a (B)asic type and not referring to a DDIC field (e.g. 8)	

Each entry in ZCLUSTDATA will appear as one table in SCR/SI.  This table will have the structure:
<ZCLUSTKEY fields>:<ZCLUSTDATA fields>
Where <ZCLUSTKEY fields> is the structure of all entries in ZCLUSTKEY matching the cluster that contains ZCLUSTDATA, and <ZCLUSTDATA fields> is the structure of the referenced Table, Structure, or Fieldname in ZCLUSTDATA.
So, the actual “table” as SCR/SI sees it is really the union of all <PIECENAME> components within clusters denoted by all keys under <DBNAME>:<RELID>.  A single “cluster” is accessed by putting the relevant key information into the selection criteria for the key fields for the cluster, or if no selection criteria are specified, all such clusters will be “unioned”.
The driver is delivered with the cluster dictionary blank.  This is because the structure of the clusters may vary from site to site and release to release.
Entering cluster definitions into the dictionary
For the current release, cluster definitions must be entered manually into the cluster dictionary tables.  This may be done either through the data browser (transaction SE16) or through table maintenance.
For each cluster:
1.	Create an entry in ZCLUSTID, specifying:
•	DBNAME as the cluster database name, such as PCL2
•	RELID as the area, such as RU

2.	Create an entry in ZCLUSTKEY for each key field which will be put together to form the actual key for the cluster, specifying:
•	DBNAME the same as the entry in ZCLUSTID
•	RELID the same as the entry in ZCLUSTID
•	KEYNUM as the number of this key within the set of keys for this cluster.  This MUST be in the same order as the structure of the key when exported.
•	KEYNAME as the name this key should be represented by in Seagate Crystal Reports/Info, such as PERNR
•	REFTABLENAME as the name of a Table or Structure in the DDIC which holds a field this key should be defined as “like”, such as PC200
•	FIELDNAME as the name of a field within the Table or Structure in the DDIC specified in REFTABLENAME which this key should be defined as “like”, such as PERNR
•	INTTYPE as the ABAP type of this key field, if not referring to a DDIC field.
•	INTLEN as the internal length of this key field, if not referring to a DDIC field.
•	NOTE:  Take care that the field names you specify for key fields of a cluster do not conflict with names for fields of the individual data pieces of that cluster.  This will cause problems when attempting to access the cluster.

3.	Create entries in ZCLUSTDATA for each “piece” of data exported to this cluster, as follows:
•	DISPNAME as the name that should be displayed as a table name for this piece of data within Seagate Crystal Reports/Info.  This name must not contain any ‘.’ Or ‘-‘ characters.
•	DBNAME the same as the entry in ZCLUSTID
•	RELID the same as the entry in ZCLUSTID
•	PIECENAME as the name to which this data piece was exported, such as RU.
•	PIECECLASS as the “class” of data that is stored in this piece.  This is either (T)able, (S)tructure, or (B)asic type.
•	REFTABNAME as the name of the table or structure to refer to for type definition of this data piece, such as PC207 for RU:RT.
•	FIELDNAME as the name of the field within the table or structure in REFTABNAME to refer to for type definition of this data piece, if it is  (B)asic type.
•	INTTYPE and INTLEN as the ABAP type and length of this data piece, if it is a (B)asic type and there is no field in a table of the DDIC that defines it.
Using Data Clusters
Once the appropriate entries have been made in the cluster dictionary, you may use clusters as you would any table within the SAP R/3 system.  In the table list, cluster names will be prefixed with ‘CL ‘.

The following example is using the report expert from Seagate Crystal Reports version 7.0.

First, you must select Clusters as a table type 

You will be presented with a list of cluster components as seen below.  In this example, we will use RGDIR from the CU cluster, and join it to ADR from the RU cluster.

We will join on PERNR and SEQNR.

Add some fields for the PERNR and the person’s address on the payroll run

Sort the results by PERNR

Restrict the resultset by PERNR

And the result – The report of peoples’ addresses by PERNR